[FLINK-40559][clients] Honor --claimMode in application mode - #29109

What is the purpose of the change

Flink silently discards an explicitly-passed --claimMode (or its deprecated alias
--restoreMode), so the recovery claim mode falls back to NO_CLAIM with no warning.
This fixes FLINK-40559, including
the shared reconstruction issue reported in
FLINK-40562.
There are three causes:

1. StandaloneApplicationClusterConfigurationParserFactory.getOptions() never registers
   SAVEPOINT_CLAIM_MODE / SAVEPOINT_RESTORE_MODE. The parser runs with
   stopAtNonOption = true, so an unrecognized --claimMode does not fail — it ends
   option parsing and the remainder is swallowed into getArgs().
2. CliFrontendParser.createSavepointRestoreSettings() reads the claim mode only inside
   the branch guarded by --fromSavepoint. Passing --claimMode without a savepoint
   path returns SavepointRestoreSettings.none() and drops it. Application-mode
   JobManagers hit this on HA recovery, where the checkpoint comes from HA storage
   rather than from a command line path.
3. SavepointRestoreSettings.fromConfiguration() returns none() when no savepoint
   path is present, dropping an explicitly configured mode during reconstruction in
   both application and session submission paths.

This is not about configuration being overwritten. Since
FLINK-39673 /
PR #28295, an unset claim
mode is no longer written to the Configuration, so a value from flink-conf.yaml
survives. The remaining defects concern CLI parsing and reconstructing pathless settings
from that configuration.

Brief change log

• StandaloneApplicationClusterConfigurationParserFactory — register
  SAVEPOINT_CLAIM_MODE and SAVEPOINT_RESTORE_MODE.
• CliFrontendParser — branch on option presence rather than on the presence of a
  savepoint path; extract parseRecoveryClaimMode(). The parsed mode is null exactly
  when neither option was passed, so an explicit --claimMode NO_CLAIM stays
  distinguishable from no override at all.
• SavepointRestoreSettings — add forRecoveryClaimMode(...) for a claim mode with no
  restore path, and extend toString() to render that state (it previously printed
  none()). Preserve pathless modes in fromConfiguration() using getOptional,
  including the deprecated execution.savepoint-restore-mode alias and canonical-key
  precedence. Absent path and absent mode still return none(), including allow-only
  configuration.

allowNonRestoredState stays null unless the flag was passed, so the new branch does
not start writing execution.state-recovery.ignore-unclaimed-state where nothing was
written before (the "explicitly set" semantics from FLINK-39673).

Option registration, parser restructuring, and shared reconstruction are separate commits.

Application and session scope

ProgramOptions.applyToConfiguration() writes the parsed mode, and
ExecutionConfigAccessor.getSavepointRestoreSettings() reconstructs it through
SavepointRestoreSettings.fromConfiguration().

Application mode also reconstructs these settings: after
StandaloneApplicationClusterEntryPoint.loadConfigurationFromClusterConfig() writes
them to the configuration, StreamGraphGenerator reads them back, and
PipelineExecutorUtils.getStreamGraph() reads them through ExecutionConfigAccessor
and sets them on the graph again. The shared fix preserves pathless modes through
both paths; the earlier session-only limitation was incorrect.

This does not retroactively override persisted HA graphs. EmbeddedExecutor can
recover an existing job ID without submitting the newly generated graph.

Verifying this change

This change added tests and can be verified as follows:

• StandaloneApplicationClusterConfigurationParserFactoryTest — --claimMode and
  --restoreMode are picked up by the application-mode parser, i.e. the options are
  registered.
• CliFrontendRunTest — pathless CLI settings now pass through ProgramOptions and
  ExecutionConfigAccessor. Parameterized application-graph coverage asserts settings
  before and after PipelineExecutorUtils.getStreamGraph() for all three modes.
• SavepointRestoreSettingsTest — fresh-configuration round trips preserve explicit
  modes and nullable/false/true allow settings; absent options and allow-only behavior
  remain unchanged. Deprecated-alias and canonical-key precedence are covered.
• StreamGraphGeneratorTest — parameterized pathless-mode propagation through the
  existing graph-generator fixture.

The original parser defects were first reproduced as failing tests on unmodified
master (expected: CLAIM but was: NO_CLAIM) and confirmed independent. For the
shared reconstruction follow-up, the settings suite failed 15 cases and the graph
propagation test failed all 3 mode cases before the production fix; both passed afterward.
Dependent client tests were skipped in the graph red run and passed in the final run.

Latest local validation (JDK 17):

./mvnw -pl flink-runtime,flink-streaming-java,flink-clients,flink-container \
  -Dtest=SavepointRestoreSettingsTest,StreamGraphGeneratorTest,CliFrontendRunTest,StandaloneApplicationClusterConfigurationParserFactoryTest \
  -Dsurefire.failIfNoSpecifiedTests=false test spotless:check checkstyle:check

109 tests passed (31 settings, 32 graph-generator, 33 CLI, 13 container); no failures,
errors or skips. Spotless and Checkstyle passed. No live-cluster failover scenario or
full clean verify was run for this follow-up.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no (no fields added; serialVersionUID unchanged)
• The runtime per-record code paths (performance sensitive): no (startup and
  graph construction/submission only)
• Anything that affects deployment or recovery: JobManager (and its components),
  Checkpointing, Kubernetes/Yarn, ZooKeeper: yes — changes how an explicit claim
  mode reaches the JobManager configuration and newly generated/submitted graphs.
  With neither a path nor an explicit mode, behavior remains unchanged. Explicit
  pathless modes are now honored instead of silently discarded.
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no — it fixes an existing CLI
  option that was silently ignored.
• If yes, how is the feature documented? not applicable

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: GitHub Copilot CLI 1.0.80; follow-up: GitHub Copilot CLI 1.0.84-5